home *** CD-ROM | disk | FTP | other *** search
/ Programming Sound Cards / Programming Sound Cards.iso / sound_89 / vocform3.doc < prev    next >
Encoding:
Text File  |  1995-01-01  |  10.2 KB  |  241 lines
  1. ─ Area: 80x86 Assembler ──────────────────────────────────────────────────────
  2.   Msg#: 38                                           Date: 01-18-93  16:00
  3.   From: Phil Inch                                    Network type: GT Power
  4.     To: Edward Schlunder
  5.   Subj: VOC file format
  6. ──────────────────────────────────────────────────────────────────────────────
  7.  
  8. Here's the format of VOC files, as promised:
  9.  
  10. BYTE(S)        NORMAL CONTENTS               PURPOSE/DESCRIPTION
  11. ---------------------------------------------------------------------------
  12.  
  13. 00 - 19        "Creative Voice File", 26     Just an identification block.
  14.                                              The quotes are not included,
  15.                                              and the 26 is byte 26 (1Ah) which
  16.                                              is an end-of-file marker.  There-
  17.                                              fore, if you TYPE a VOC file, you
  18.                                              will just see Creative Voice File.
  19.  
  20. 20 - 21        26, 00                        This is a low byte, high byte
  21.                                              sequence which gives the offset
  22.                                              of the first block of sound data
  23.                                              in the file.  Currently this is
  24.                                              26 ( 00 x 256 + 26 ) which is the
  25.                                              length of the header, but it's
  26.                                              probably good programming practice
  27.                                              to read and use this value anyway
  28.                                              in case the format changes later.
  29.  
  30. 22 - 23        10,1                          These bytes give the version
  31.                                              number of the VOC file, subnumber
  32.                                              first, then main number.  The
  33.                                              default, as you can see, is 1.10.
  34.  
  35. 24 - 25        41,17                         These bytes are "check digits".
  36.                                              These allow you to be absolutely
  37.                                              SURE that you are working with a
  38.                                              VOC file.  To use them, convert
  39.                                              the version number (above) and
  40.                                              this number to integers.  Do this
  41.                                              with the formula below, where for
  42.                                              convention the above bytes have
  43.                                              been listed as byte1, byte2.
  44.  
  45.                                              (byte2*256)+byte1
  46.  
  47.                                              Therefore, for the default values
  48.                                              we get the following integers:
  49.  
  50.                                              (1 x 256)+10     =  266
  51.                                              (17 x 256)+41    = 4393
  52.  
  53.                                              When you add the two results, you
  54.                                              get 4659.  If you do these calcs
  55.                                              and get 4659, then you can be
  56.                                              almost certain you're working with
  57.                                              a VOC file.
  58.  
  59. OK, that takes care of the header information.  I hope you realise that I'll
  60. never get a registration for VOCHDR now!  Oh well <sigh> perhaps people will
  61. buy my games!
  62.  
  63.    Having gotten to byte 26, we now start encountering data blocks.  There
  64. are eight types in all, conveniently numbered 0 - 7.  For each block, the
  65. first byte will always tell you the type.
  66.  
  67. For notational convenience, bx means byte x, eg b5 means byte 5.
  68.  
  69. BLOCK 0 - THE "END BLOCK"
  70.  
  71.    Structure:     Byte 1: '0' to denote "end block" type
  72.  
  73.    This block is located at the END of a VOC file.  When a VOC player
  74.    encounters a block 0, it should stop playing the VOC file.
  75.  
  76.  
  77. BLOCK 1 - THE "DATA BLOCK"
  78.  
  79.    Structure:     Byte 1: '1' to denote "data block" type
  80.  
  81.                        2: \
  82.                        3: | These bytes give the length:
  83.                        4: / b2 + (b3*256) + (b4*65536)
  84.  
  85.                        5: Sampling rate: Calculated as 1000000 / (256-b5)
  86.  
  87.                        6: Pack type byte:
  88.                               0 = data is not packed
  89.                               1 = data is packed to four bits
  90.                               2 = data is packed to 2 bits
  91.                               3 = data is packed to 1 bit
  92.  
  93.                        7: Actual sample data starts here
  94.  
  95.  
  96. BLOCK 2 - THE "MORE DATA BLOCK"
  97.  
  98.    Structure:     Byte 1: '2' to denote "more data block" type
  99.  
  100.                        2: \
  101.                        3: | These bytes give the length:
  102.                        4: / b2 + (b3*256) + (b4*65536)
  103.  
  104.                        5: Actual sample data starts here
  105.  
  106.    The point of this is simple:  If you have a sample that you want to chop
  107.    up into smaller portions (the maximum block length in a VOC file is
  108.    16,842,751 bytes but who's counting?), then define a "more data" block.
  109.    This "carries over" the previously found sampling rate and pack type byte,
  110.    so a "data block" should have been encountered earlier somewhere along
  111.    the line.
  112.  
  113.  
  114. BLOCK 3 - THE "SILENCE" BLOCK
  115.  
  116.    Structure:     Byte 1: '3' to denote "silence block" type
  117.  
  118.                        2: \
  119.                        3: | These bytes give the length:
  120.                        4: / b2 + (b3*256) + (b4*65536)
  121.  
  122.                           (Note that this value is usually 3 for a
  123.                           silence block.)
  124.  
  125.                        5: Duration ( b5+(b6*255) ).  This gives the equivalent
  126.                        6: number of bytes to "play" during the silence.
  127.  
  128.                        7: Sampling rate: Calculated as 1000000 / (256-b5)
  129.  
  130.    A silence block is used for long periods of silence.  When long silences
  131.    are required, it's more efficient in size terms to insert one of these
  132.    blocks, as seven bytes can then represent up to 65,536.
  133.  
  134.  
  135. BLOCK 4 - THE "MARKER BLOCK"
  136.  
  137.    Structure:     Byte 1: '4' to denote "marker block" type
  138.  
  139.                        2: \
  140.                        3: | The length of the block, as usual
  141.                        4: /
  142.  
  143.                        5: Marker value, as low-high (ie b5 + (b6*255) )
  144.                        6:
  145.  
  146.    The marker block is read by CT-VOICE.DRV.  When a marker block is
  147.    encountered, the value in the marker value bytes (5 and 6) is copied into
  148.    the status word specified when CT-VOICE was initialized.
  149.  
  150.    This allows your program to judge where in the sample you currently are,
  151.    thus allowing for progress counters and the like.  It's also useful if
  152.    you're trying to synchronize other processes to the playing of the sound.
  153.  
  154.    For example, by using appropriate marker blocks, you could send signals
  155.    to your software to move the lips of a person on-screen in time with the
  156.    speech in the VOC.  However, this does take some doing and a VERY good
  157.    VOC editor!
  158.  
  159.  
  160. BLOCK 5 - THE "MESSAGE BLOCK"
  161.  
  162.    Structure:     Byte 1: '5' to denote "message block" type
  163.  
  164.                        2: \
  165.                        3: | The length of the block, as usual
  166.                        4: /
  167.  
  168.                    5 - ?: Message, as ASCII text.
  169.  
  170.                        ?: 0, to denote end of text
  171.  
  172.    The message block simply allows you to embed text into a VOC file.
  173.    Presumably you could use this to detect when other people have pinched
  174.    your VOC files for their own applications.
  175.  
  176.  
  177. BLOCK 6 - THE "REPEAT BLOCK"
  178.  
  179.    Structure:     Byte 1: '6' to denote "repeat block" type
  180.  
  181.                        2: \
  182.                        3: | The length of the block, as usual
  183.                        4: /
  184.  
  185.                        5: Number of times that data should be repeated
  186.                        6: Total = 1 + b5 + (b6*255)
  187.  
  188.    Every "playable" data block between a block 6 and a block 7 will be repeated
  189.    the number of times specified in b5 and b6.  Note that you add one to this
  190.    value - the data blocks are ALWAYS played at least once.  However, if b5
  191.    and b6 are zero, then you really don't need a repeat block, do you!
  192.  
  193.    I'm told that you cannot "nest" repeat blocks, but I've never tried it.
  194.    This limitation would only apply to CT-VOICE.DRV I would have thought, but
  195.    it depends how good other VOC players are.
  196.  
  197.  
  198. BLOCK 7 - THE "END REPEAT BLOCK"
  199.  
  200.    Structure:     Byte 1: '7' to denote "end repeat block" type
  201.  
  202.                        2: \
  203.                        3: | The length of the block, as usual
  204.                        4: /
  205.  
  206.    This, as explained, marks the end of the block of blocks (!) that you wish
  207.    to repeat.  Note that the "length" is always zero, so I don't know why
  208.    the length bytes are required at all.
  209.  
  210. ------------------------------------------------------------------------------
  211.  
  212. WELL, that's it!  Phew, what a lot of typing.  I hope you lot are all
  213. grateful!
  214.  
  215. Now I have a favour to ask; does ANYONE have the technical specs for
  216. programming the SB (and SBPRO)?  I mean the low-level stuff, not how to access
  217. CT-VOICE and SBFMDRV (which I already know).  If you do, get in touch as I
  218. really need this info.
  219.  
  220. I faxed Creative Labs with this request but so far, no reply.  Admittedly it
  221. has only been four days, maybe they are sending a reply snail-mail.  Who knows.
  222. Ah well.
  223.  
  224. Regards
  225. Phil
  226.  
  227.   Route: 302/0m20 81/1 */* 32/1tu8 32/3
  228. .ORIGIN: 302/000 - The Poet's Dilemma - Sydney/Oz - +61-2-8731642/1643
  229.  
  230.  
  231.       My thanks go to Phil Inch in Australia for taking the time to compose
  232.    this great piece of work. It must have taken many hours of his time to
  233.    search his books, and then understand his books to come up with this.
  234.  
  235.       He did this all for free and now he won't get registrations for his
  236.    VOCHDR program. Please, if you find his program, register it if you
  237.    like it. Please, don't use this information against Phil, create a
  238.    program unlike Phil's and register Phil's program.
  239.  
  240.       - Edward T. Schlunder
  241.